智汇华云 | 初识 Serverless
前言
Serverless是一种云原生开发模型，可使开发人员专注构建和运行应用，而无需管理服务器。Serverless方案中仍然有服务器，但它们已从应用开发中抽离了出来。云提供商负责置备、维护和扩展服务器基础架构等例行工作。开发人员可以简单地将代码打包到容器中进行部署。本期智汇华云，带大家一同了解Serverless。
背景
从部署物理机到虚拟机过程中，云计算通过虚拟化的方式对算力资源进行了更高效的分配。为了更细粒度的分配，容器在云计算发展浪潮中诞生了。那有没有可能再进一步，将一次业务执行作为单元进行算力分配呢？每当执行的时候才分配一次资源，否则不消耗。答案就是 Serverless。
什么是Serverless
Serverless （无服务器架构）并不是严格意义上的无服务器，因为无论如何抽象或者封装底层设备，程序总是要有一个服务器作为物理载体才能运行。Serverless 的概念更加强调计算资源的自由扩展，无需手动人工配置。
Serverless 是由事件驱动的全托管计算服务。用户无需管理服务器等基础设施，只需要编写代码和选择触发器（比如 RPC 请求，定时器等）并上传。其余的工作（如实例选择，扩缩容、监控、日志、容灾、部署等）全部由 Serverless 系统托管。
Serverless 通常包含了两个领域 BaaS和 FaaS，其中 BaaS 可以理解成特定类型的托管服务，例如数据库服务、对象存储服务、日志服务等等，而 FaaS 即为云函数计算服务，提供核心的逻辑处理。
Serverless 实践
基于Kubernetes的 Serverless framework 有很多，例如 Knative、OpenFaaS、OpenWhisk 等等，这里以 OpenFaaS 为例。
OpenFaaS 部署
OpenFaaS 可以通过 arkade、helm3 以及 manifests yaml 等方式部署，部署后共有以下组件：
为了方便后续函数管理，这里也一并部署了 faas-cli，并配置了 Gateway Service 暴露的入口地址：
OpenFaaS 工作流程
OpenFaaS Gateway
Gateway作为请求网关，当要部署或者调用一个函数的时候，Gateway会将请求转发给Provider（faas-netes），同时会将监控指标发给Prometheus。AlertManager会根据需求，调用API自动伸缩函数。
Prometheus & AlertManager
收集 Gateway 的 auto-scaling 指标，结合实际情况，自动伸缩函数的规模。
NATS Streaming
NATS Streaming 是由 NATS 驱动的数据流系统，在保证吞吐量和时延的基础上，解决了Nats消息投递一致性的问题。在 OpenFaaS 中作为处理函数调用的低延迟队列。
faas-netes
faas-netes 是faas-provider 的官方实现。
faas-provider 中定义了一些基本的 faas handler规范，如下所示：
OpenFaaS 使用
OpenFaaS 创建函数可以通过 REST API，faas-cli 或者 GateWay UI 三种方式创建，这里以 faas-cli 为例：
下载模版
首先下载官方提供的语言模版，模版支持 go，java11，python2(3)，php7(8)，ruby 等诸多语言
生成应用
通过 faas-cli new 创建一个 go 应用，修改 handler 函数，简单模拟一个计算服务（计算入参的和）：
构建镜像
部署应用
服务访问
也可以通过界面访问或者部署服务
自动扩缩容
可以通过 label 的配置，将服务默认为0副本，当请求到达时，会根据副本范围、缓冲期，扩缩模式等规格自动扩容，请求结束后，并自动缩容。
OpenFaaS 自动扩缩容源码分析
Prometheus将监控指标发给AlertManager之后，AlertManager会调用 /system/alert接口，这个接口的handler是由handlers.MakeAlertHandler方法生成。MakeAlertHandler方法接收的参数是ServiceQuery。ServiceQuery是一个接口，它有两个函数，用来获取或者设置最大的副本数。
MakeAlertHandler的函数主要是从http.Request中读取body，然后反序列化成PrometheusAlert对象：该对象是一个数组类型，支持对多个函数进行缩放。反序列化之后，调用handleAlerts方法，而handleAlerts对Alerts进行遍历，针对每个Alerts调用了scaleService方法。scaleService才是真正处理伸缩服务的函数。
Serverless 使用场景
在了解Serverless的应用场景之前，首先总结一下它的技术特点：
- 快速迭代与部署
- 高并发、高弹性
- 稳定、可靠、安全
- 运维与成本控制
如果应用复杂有显著的波峰波谷、对快速迭代有强烈诉求，Serverless就可以发挥显著的作用。
但是，由于Serverless的无状态性，状态管理和共享仍然很困难，因此在使用场景下也具有局限性。
综合而言，Serverless比较适合以下场景：
- 机器学习及 AI 模型处理
- 图片处理、文件处理以及流处理
- IoT 后端及移动后端
Serverless 的价值
无服务器管理
无需预置或维护任何服务器。无需安装、维护或管理任何软件或运行时。
灵活扩展
应用程序可自动扩展，或通过切换占用资源（如吞吐量、内存）的单位数（而不是切换单个服务器的单位数）来调整容量，从而实现扩展。
按价值付费
为一致的吞吐量或执行持续时间（而不是服务器单元）付费。
自动化的高可用
无服务器应用程序提供内置可用性和容错功能。无需构建这些功能，因为运行此应用程序的服务在默认情况下会提供这些功能。
Serverless现阶段的不足
状态管理
要想实现自由的缩放，应用的无状态是必须的，而对于有状态的服务而言，使用 Serverless就丧失了灵活性，有状态服务需要与存储交互就不可避免的增加了延迟和复杂性。
延迟
应用程序中不同组件的访问延迟是一个大问题，传统架构中可以通过专有的网络协议、RPC 调用、实例拓扑等方面优化，而 Serverless应用程序是高度分布式、低耦合的，这就意味着延迟将始终是一个问题，单纯使用Serverless的应用程序是不太现实的。
结语
Serverless的出现能够解决备份容灾、计费方式、弹性伸缩、资源分配的等棘手问题，尽管现阶段 Serverless 架构存在很多不足，但是诸多的优良特性决定它是大势所趋。随着Serverless 生态圈多样化发展，它无疑是非常令人期待并且前景光明的方向。
点“在看”给我一朵小黄花